In the field of graphics applications, a texture defines information that can be mapped onto a face of a graphical object. For example, a graphics application can create various objects that simulate the shape a brick wall. A texture bearing the surface appearance of a brick wall can then be mapped to the surface of the objects to create the visual appearance of a brick wall. In general, texture mapping enhances the visual complexity of the 3D objects with relatively small increase in computation.
It may require a significant amount of memory to store raw textures. For this reason, graphics applications commonly compress the textures. In view of the typical use of textures (such as game applications), a compression technique used to compress textures must accommodate the random access of texture information. Thus, not every image compression technique can effectively be used to compress textures.
One commonly used technique to compress textures is S3 Texture Compression (S3TC), which is also referred to as DXTn or DXTC. As to high-level characteristics, S3TC formats use fixed length coding (FLC). Typically, S3TC formats can provide a compression ratio of 8:1 or 4:1 for 32 bpp ARGB textures with little loss in visual quality. S3TC texture images comprise a collection of 4×4 texel blocks, where each block contains 64 or 128 bits of texel data. (A “texel” refers to a unit of texture information.) A S3TC texture image is encoded as a normal 2D raster image in which each 4×4 block is treated as a single pixel.
There are five common S3TC textures formats: DXT1; DXT2; DXT3; DXT4; and DXT5. The different types of S3TC formats are summarized below.
DXT1
The DXT1 texture format can be used for textures that are opaque or have a single transparent color. This format uses 64 bits for each DXT1 block. FIG. 1 shows the layout of an exemplary DXT1 block. The block includes 32 bits of main color information 102 and 32 bits of color index information 104, together defining 16 pixels. More specifically, the color of each pixel in the block can be constructed based on a combination of the main color information 102 and the color index information 104. That is, a 2-bit color index in the color index information 104 specifies the color of an associated pixel, as selected from four color candidates, i.e. color_0, color_1, color_2 and color_3 defined by the main color information 102. Both of the main colors (C0 and C1) are expressed in RGB 5:6:5 format and determine whether the current block is an opaque block or a 1-bit alpha block.
For opaque blocks, the first main color C0 is greater than C1 , and the four candidate colors are:color—0=C0color—1=C1color—2=(2×C0+C1+1)/3color—3=(C0+2×C1+1)/3
Otherwise, for 1-bit transparent blocks, the four candidate colors are:color—0=C0color—1=C1color—2=(C0+C1)/2color—3=transparent
More generally stated, DXT1 compression operates by linearly fitting all of the 16 pixels in RGB space based on the main colors, where the main colors determine the endpoints of the line segment. The main colors, together with one or two interpolated colors, make a block palette from which the color indices choose the most appropriate color for each pixel. Such a solution works well in practice in many cases, mainly because the local color distribution of most computer-generated images can be represented by linear fitting, unlike the case of many natural images. Further, for the regions in which linear fitting does not work well, the small size of the 4×4 block produces acceptable levels of distortion in the block.
DXT3
The format of DXT3 differs from DXT1's 2-level transparency. More specifically, the compression format of DXT3 uses an alpha 4×4 bitmap for each block preceding 64 bits describing the block color information, to thereby exhibit more complex alpha information. Note the example of a DXT3 block shown in FIG. 2. The block includes color information 202 in combination with 64 bits of alpha information 204. The 64-bit color information 202 is the same as the 64-bit opaque DXT1 color information (102, 104), with the exception that C0 may be not greater than C1 in the case of DXT3. The alpha information 204 stores, for each pixel, 4-bit alpha data. The 4-bit alpha data can be produced through a variety of approaches, such as by dithering or by using the four most significant bits of the original alpha data.
DXT5
The DXT5 format, like the DXT3 format, uses 128 bits to describe a 4×4 block. FIG. 3 shows an exemplary DXT5 block. This block includes 64 bits of color information 302. The DXT5 64-bit color information 302 is identical to that of DXT1 and DXT3. Like DXT3, the DXT5 format differs from the DXT1 format by including 64 bits of alpha information 304. Unlike DXT3, the alpha information 304 includes 48 bits of alpha index information 306 together with 16 bits of main alpha information 308, comprising alpha information A0 and alpha information A1. The 48 bits of alpha index information 306 store 3 bits of index data per pixel.
DXT5 alpha encoding operates on a principal similar to the linear fitting used for color blocks (as described above for DXT1). That is, each pixel's corresponding 3-bit alpha index chooses its alpha value from eight candidate alpha values, alpha_0, alpha_1, . . . , and alpha_7, all of which are derived from the endpoint values defined by A0 and A1. If A0 is greater than A1, six intermediate alpha values are generated by interpolation:alpha—0=A0alpha—1=A1alpha—2=(6×A0+1×A1+3)/7alpha—3=(5×A0+2×A1+3)/7alpha—4=(4×A0+3×A1+3)/7alpha—5=(3×A0+4×A1+3)/7alpha—6=(2×A0+5×A1+3)/7alpha—7=(1×A0+6×A1+3)/7
Otherwise, only four intermediate alpha values are interpolated, and the other two alpha values are 0 (fully transparent) and 255 (fully opaque):alpha—0=A0alpha—1=A1alpha—2=(4×A0+1×A1+3)/5alpha—3=(3×A0+2×A1+3)/5alpha—4=(2×A0+3×A1+3)/5alpha—5=(1×A0+4×A1+3)/5alpha—6=0alpha—7=255
DXT2 and DXT4
DXT2 compression format is similar to DXT3, while DXT4 compression format is similar to DXT5. DXT2 and DXT4 differ from the above-described formats in that the pixel color values are multiplied by their corresponding alpha values before compression. This can speed up some compositing operations, but it can have the negative effect of losing color information. For this reason, DXT2 and DXT4 are not as widely used in practice as DXT1, DXT3, and DXT5.
S3TC formats are widely used. Nevertheless, these formats may not yield desired performance in all cases. For example, graphics applications continue to incorporate increasing numbers of textures. Further, graphics applications continue to use textures of increasingly larger size. Graphics applications also strive for faster processing speeds to support real-time rendering for complex scenes. These types of demands are particularly prevalent in modern 3D game and simulation applications. These demands raise at least two challenges. First, these types of applications may use a significant amount of memory to store the textures. Second, the applications may take a significant amount of time to load the textures from peripheral devices to memory. This loading time may be longer than the amount of time required by a graphics processing unit (GPU) to consume the data, thus making the loading operation a bottleneck to the speed of the graphics application as a whole. These types of challenges are not necessarily overcome by compressing the textures using S3TC. This is because S3TC compression produces a relatively large file size.
There have been some efforts in devising new texture formats to produce enhanced compression ratios. However, these efforts have not yielded fully satisfactory results. Typically, when the texture compression ratio is increased, the visual quality deteriorates. This type of problematic trade-off occurs, for instance, in fixed length coding (FLC) compression techniques (such as S3TC). Variable length coding techniques (VLC) are widely used in image and video compression applications and provide a satisfactory treatment of compression rate and distortion issues. However, VLC does not support random access well, which makes it ill-suited for texture compression in graphics applications. Another approach is to convert some other kind of non-S3TC format (with a better compression ratio than S3TC) to the S3TC format. But this kind of conversion may be time-consuming, so that it cannot effectively be performed a real-time fashion.
For at least one or more of the above-identified exemplary and non-limiting reasons, there is a need in the art for more satisfactory strategies for compressing and decompressing texture information.